13B: Notices split into a writer and a presenter - #22

What: Notices\Queue splits into Notices\Writer (words a notice, stores it under slug:type, behind the new Writer_Interface) and Notices\Presenter (the activate_plugins gate and the render-then-clear, bound by class name); Absorber::notices() returns the writer and Absorber::render_notices() resolves the presenter.

Usage:

// Reword every notice without touching where they are kept or how they are drawn.
$container->singleton( Writer_Interface::class, My_Notice_Writer::class );

Why this way:

The name was wrong and the class was two jobs. Queue never held the queue — Store does — and it answered both "what does this notice say" and "who may see the pending set, and is it gone once they have". A host already running its own notices library has an opinion about the first and none about the second.

Only the writer earns a contract. Nothing in the library dispatches on how a notice reaches the screen: the all_admin_notices trampoline is the presenter's only caller, so a host that wants none of our rendering takes that callback off rather than binding an implementation that does nothing.

The capability check goes with render-and-clear, not with the markup. It guards the clearing as much as the drawing, so deciding those separately would let a user who may not see the queue destroy it anyway, through a class that never checked.

No behaviour changes. It is a move, which is why it exceeds the usual source-file cap.

Summary by CodeRabbit

• New Features

  • Added separate notice writing and presentation components.
  • Notices are now rendered only for authorized administrators and cleared after display.
  • Added support for independently customizing notice wording, storage, rendering, and presentation.

• Documentation

  • Updated architecture, configuration, and notice-rendering documentation to reflect the new notice workflow.

• Tests

  • Expanded coverage for notice writing, persistence, rendering, permissions, sanitization, and queue handling.